Summary of changes

This PR introduces three new abstractions:

1. Resolver: Resolves which reader and writer to use for a template.
2. Writer: Writes a template project to disk. Prompts the user if necessary.
3. Reader: Reads a template specification from disk, built into the CLI or from GitHub.

Introducing these abstractions helps decouple reading a template from writing it. When I tried adding telemetry for the bundle init command, I noticed that the code in cmd/init.go was getting convoluted and hard to test. A future change could have accidentally logged PII when a user initialised a custom template.

Hedging against that risk is important here because we use a generic untyped map<string, string> representation in the backend to log telemetry for the databricks bundle init. Otherwise, we risk accidentally breaking our compliance with our centralization requirements.

Details

After this PR there are two classes of templates that can be initialized:

1. A databricks template: This could be a builtin template or a template outside the CLI like mlops-stacks, which is still owned and managed by Databricks. These templates log their telemetry arguments and template name.
2. A custom template: These are templates created by and managed by the end user. In these templates we do not log the template name and args. Instead a generic placeholder string of "custom" is logged in our telemetry system.

NOTE: The functionality of the databricks bundle init command remains the same after this PR. Only the internal abstractions used are changed.

Tests

New unit tests. Existing golden and unit tests. Also a fair bit of manual testing.